REMARKS 

Reconsideration and removal of the grounds for rejection are respectfully 
requested. Claims 1-15 and 17-46 were in the application, claims 1-15 and 17 were 
withdrawn, claims 18-21, and 23-26 have been amended, claims 27-29 and 33-46 have 
been cancelled, and new claims 47 and 48 have been added. 

The examiner objected to Figure 5, and a replacement sheet corrected per the 
examiners' suggestion is enclosed herewith. 

The specification has been amended per the examiners' suggestion to spell out 
the various abbreviations used in the application, as well as to capitalize JAVA with the 
generic description, as well as to provide proper attribution for the Java® trademark. 
Consequently, the objections are now moot. 

Claim 18 has been amended to incorporate the limitations of dependent claims 
19, 20, 27 ,28 and 29. Method claims 33-46 have been deleted and replaced by a single 
new independent method claim 49 of corresponding scope to amended claim 18. 

Claim 18 has also been amended to include features found in the description 
which are believed to further distinguish the invention from Coleman, as will be 
discussed further below. In particular, claim 18 now specifies that the input processor is 
further configured to: (1) Add static data to the data corresponding to the received 
invoices when processed into the standard intermediate form; (2) Add dynamic data to 
the data corresponding to the received invoices when processed into the standard 
intermediate form; and (3) Validate the data corresponding to the received invoices 
when processed into the standard intermediate form before transmission by the 
transmitter to the party being invoiced. Support for feature (1) can be found in previous 
claim 28 and also on page 10, line 33, page 11, line 1 and step s204 shown in Figure 8. 
Feature (2) finds support on page 11, line 1 and step s205 shown in Figure 8. Feature 
(3) finds support on page 11, lines 2,3 and step s207 shown in Figure 8. No new matter 
is involved in this amendment. 

Claims 18 -46 were rejected as being anticipated by U.S. Patent no. 5,708,828 to 
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Coleman. 

The applicant has given consideration to the examiners comments that the 
applicants invention relates to data, however to characterize this as "nothing more than 
data is an overly broad interpretation, There are myriad subsets of data, just as there are 
myriad subsets of devices, and as should be understood, it is the language of the claim 
that is looked to for direction as to the subset of data, or devices, to which a claim is 
directed, and the Examiner cannot ignore claim language, as this sets the bounds of the 
invention. The Examiner thus must take into consideration that certain subsets of data 
will require different processing that other subsets of data, and just as with devices, 
have different problems, advantages and features associated with that particular subset. 
This is particularly important when making a determination of anticipation, as the legal 
requirements for anticipation apply to all inventions, including those dealing with data. 

"The term 'anticipation' in patent usage means that the invention was previously 
known to the public; that is, that it previously existed in the precise form in which it is 
claimed, including all of the limitations in the claim ." SmithKlinc Bcccham Corp. v. 
Apotex Corp., 439 F.3d 1312, 1324 (Fed. Cir. 2006) (Emphasis added.) 

"A claim cannot be 'anticipated' by prior art that does not have all of the 
limitations in the claim." Helifix Ltd. v. Blok-Lok, Ltd., 208 F.3d 1339, 1346 (Fed. Cir. 
2000) SmithKline Beecham Corp. v. Apotex Corp., 439 F.3d 1312, 1324 (Fed. Cir. 
2006) 

As discussed above, claim 18 has been amended to add that the input processor 
is configured to: 

add static data to the data corresponding to the received invoices when 
processed into said standard intermediate form; 

add dynamic data to the data corresponding to the received invoices when 
processed into the standard intermediate form; and, 

validate the data corresponding to the received invoices when processed into the 
standard intermediate form before transmission by said transmitter to the party being 
invoiced. 
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In accordance with the invention, the invoice data received from individual 
sources are processed by an input processor (6a, 6b) that converts the input data into a 
standard intermediate form according to a mapping definition (6b) selected depending 
on the source of the data. The converted signals are held in a data warehouse. 
Subsequently, an output processor (9a), (9b) processes signals from the data warehouse 
depending on the destination according to a mapping definition that is selected 
depending on the destination. 

Typically, senders of invoice data may not want to or may not be able to extract 
all of the information required from their local system in order to generate a legally 
compliant invoice. This is solved by feature (1) of amended claim 18, as the apparatus 
can augment the data received with additional information held for the individual 
sender as static data, in order to supplement the inbound data file. 

As an example, a sender of invoice data would not normally send their own 
name, address and tax registration information in an invoice data file as this would 
traditionally be pre-printed on their own stationary and hence not be held in their 
system. However, it is often a legal requirement to include such name and address 
information in the invoice and therefore must be present in some jurisdictions. 

On receipt of a data file from the supplier, the present invention as now claimed 
can check for the presence of name, address and tax registration information and if it 
not present, it can be retrieved from the client's profile and added to the data file in the 
standard intermediate form for processing and onward transmission. Also, some data 
components in the received invoice data are relationship based and the internally 
generated data needs to take into account, i.e., who has sent the data and who the 
receiver of the data will be. This is solved by feature (2) of amended claim 18. For 
example, within the receiver's system, the identity of inbound invoice data may be 
based on the sender's vendor code, held in the receiver's master file. The sender is not 
aware of code and therefore cannot provide it in their data. However, the invoice 
routing apparatus as now claimed permits a receiver of data to set up sender's aliases so 
that when a transaction is received from particular sender, the invoice routing apparatus 
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retrieves the receiver's code for the sender from a local store and adds this data to a 
specified field in the standard intermediate format so that when the output processor 
generates signals for transmission to the party being invoiced i.e. the receiver, they can 
contain code data that the receiver will recognize. 

Claim 18 also includes a third feature (3) directed to validation of the data in the 
standard intermediate form before transmission to the party being invoiced. This 
ensures a high quality of data being supplied to the invoice parties, thereby resulting in 
a reduced failure rate for transmission of data. 

Coleman does not disclose a system containing these features, precisely or any 
other way, and thus claim 18 and the claims depending therefrom are not anticipated by 
Coleman. 

Moreover, there is nothing to lead one skilled in the art to include the above 
mentioned three features which now have been incorporated into claim 18, and claim 18 
is not obvious over Coleman. 

Based on the above, favorable consideration and allowance of the application 
are respectfully requested. However should the examiner believe that direct contact 
with the applicant's attorney would advance the prosecution of the application, the 
examiner is invited to telephone the undersigned at the number given below. 

Respectfully submitted, 

/WJS/ 
William J. Sapone 
Registration No. 32,518 
Attorney for Applicant(s) 

Coleman Sudol Sapone P.C. 
714 Colorado Avenue 
Bridgeport, CT 06605 

Telephone No. (203) 366-3560FacsimileNo. (203) 335-6779 
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MARKED UP SPECIFICATION PARAGRAPHS 



On page 4, the paragraph extending from lines 14-30 is amended to read as follows: 

Figure 1 is a generalised dataflow diagram of a system including a routing apparatus 
according to the present invention; 

Figure 2 is a generalised dataflow diagram of a further system including a routing 
apparatus according to the present invention; 

Figure 3 shows the elements of system employing an open systems interconnection 
(OSI) ©SI layer 7 routing apparatus of the form illustrated in Figure 2; 
Figure 4 illustrates the configuration of the web server machine of Figure 3; 
Figure 5 is a flowchart illustrating a first method for the transfer of invoice data to the 
invoice routing system of Figure 3; 

Figure 6 shows the user interface of an applet used in the method illustrated in Figure 5; 
Figure 7 is a flowchart of a method of generating invoices using the invoice routing 
system of Figure 3; 

Figure 8 is a flowchart of an input signal conversion process; 

Figure 9 is a flowchart of an output signal conversion process; Figure 10 is a flowchart 
of a invoice file download process; and 

Figure 1 1 illustrates a mapping definition file used by the system shown in Figure 3. 

The paragraph on page 6, extending from lines 25-28, is amended to read as follows: 
The present invention may be implemented at various layers of the International 
Standards Organization (ISO) ISO networking reference model. An application layer, 
i.e. layer 7, embodiment for the transfer of invoice data, including credit note data and 
the like, will now be described by way of example. 



The two paragraphs on page 8, extending from line 10-15 are amended to read as 
follows: 
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The supplier, buyer, head office and fiscal authority computers 15, ... , 22 all interact 
with the invoice routing system 14 through the agency of the web server machine 23 
and do not need to have software other than a Java JAVA® software -enabled web 
browser in order to make use of the invoice routing system 14. (Java® is a registered 
trademark of Sun Microsystems, Inc.) 

Referring to Figure 4, the web server machine 23 supports a web server 40 enabled for 
secure communication, e.g. using SSL (secure sockets layer), a plurality of computer 
graphics interface (CGI) GGi scripts 41, a fue reception process 42 and a file 
transmission process 43. 

On page 8, the paragraph extending from lines 22-30 is amended to read as follows: 
Referring to Figure 5, in order to upload invoice data to the invoice routing system 14, 
the operator of the first supplier computer 1 5 uses a web browser to "log in" to the web 
server 40 and establish a secure communication path (step si). Having logged in, the 
operator can follow a hypertext link to an invoice file upload page (step s2). The file 
upload page includes a Java JAVA software applet. The Java applet is signed so that it 
has access to the file system of the first supplier computer 15. As shown in Figure 6, the 
applet's user interface includes a list box 50 for listing the files to be uploaded, a button 
5 1 for opening a file selection dialog so that the operator can specify the invoice files to 
be uploaded and a button 52 for starting the file transfer. 

On page 9, the paragraph extending from lines 17-23 is amended to read as follows: 
The third supplier computer 17 uses an automatic upload process. This process is 
triggered by scheduling software on the third supplier computer 17 and is effected by a 
Java JAVA software application which performs a file transfer protocol (FTP) 
transmission FTP over an HTTP a hypertext transfer protocol (HTTP) link to the web 
server machine 23 and prohibits operator intervention. The use of FTP over an HTTP 
link avoids the need for a direct FTP link between the third supplier computer 17 and 
the invoice routing system 14. The use of this, and the prohibition of operator 
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intervention increases system security. 

The paragraph on page 13, extending from lines 1-6 is amended to read as follows: 
Following the successful download of an invoice file, individual invoices are also sent 
to the respective buyer via e-mail in hypertext markup language (HTML) HTML 
format. These invoice copies may include data, such as value added tax (VAT) VAT 
registration numbers, that is not included the downloaded invoice file but which is 
required on printed invoices, which themselves may be a legal requirement. 
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